The vreg and vsreg registers technically accept #[repr(simd)] types, but require the experimental altivec or vsx target features to be enabled. That work seems to be tracked here, #42743.

These also accept f32 and f64 (as per the docs in rust-lang/reference#2056). Even though the target features are unstable, these are still usable on targets where these features are enabled by default. Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

• r[29-30]: Reserved for internal usage by LLVM

r29 is only reserved on ppc32. We could allow r29 for powerpc64 only.

• fpscr: it is not modelled by gcc or llvm.
• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

It would be good to document these as being controlled by preserves_flags like we do in RISC-V. That way when LLVM eventually adds support for modelling these then code will continue to properly handle them.

Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

Specifically that would require a PR like #145656 for s390x, which stabilizes the target features (and presumably also the is_powerpc_feature_detected macro).

I'd assume that with this PR merged, stabilizing the vsx and altivec target features at least would be straightforward if there is appetite. If so, it's probably a good idea to ensure (via tests) that the interaction between vector types and asm works as expected.

@pmur

• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

However, I guess LLVM/GCC could potentially generate code that relies on the VSCR fields being the same before and after inline assembly, when it is not marked as clobbered.

• spe_acc, spefscr: These are available exclusively on the SPE target (the e500, not cell). I am not sure how these are actually used. I think they can be added later if needed.

IIRC, these are used to store the results of SPE-specific instructions.

That said, since all SPE targets are tier 3, it might be fine to ignore them and proceed with stabilization.

@folkertdev

Passing SIMD vectors will remain implicitly unstable as long as the relevant stdarch bits are unstable.

Specifically that would require a PR like #145656 for s390x, which stabilizes the target features (and presumably also the is_powerpc_feature_detected macro).

AFAIK, when passing values to inline assembly, the required target features themselves do not need to be stable (since #114467).

Btw, s390x is a bit special in that passing values to vector registers in inline assembly requires a separate unstable feature: #133416 (This is due to vector ABI support being added after the inline assembly stabilization.)

@taiki-e

• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

However, I guess LLVM/GCC could potentially generate code that relies on the VSCR fields being the same before and after inline assembly, when it is not marked as clobbered.

Yes, that would make it even more difficult to correctly mark this a clobber. Making it unusable avoids the question of whether codegen will actually preserve it.

@Amanieu

• fpscr: it is not modelled by gcc or llvm.
• vscr: clang/gcc accept this as a clobber, but do not actually save/restore it.

It would be good to document these as being controlled by preserves_flags like we do in RISC-V. That way when LLVM eventually adds support for modelling these then code will continue to properly handle them.

I think the consensus is not to preserve any flags. Notably, XER is partially modeled, but we choose to ignore it. It depends on if and how LLVM/GCC would choose to expose it.

@Amanieu

r29 is only reserved on ppc32. We could allow r29 for powerpc64 only.

Yes, that seems reasonable. See #148492.

In general, is there any issue against relaxing restrictions post stabilization? Particularly, if we add FPSCR/VSCR preservation requirements for preserves_flags which we cannot enforce today.

For FPSCR, are there active plans to support it in LLVM?

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

I think the consensus is not to preserve any flags. Notably, XER is partially modeled, but we choose to ignore it. It depends on if and how LLVM/GCC would choose to expose it.

At the very least we need to ensure that clobber_abi correctly treats these as clobbered at the LLVM level, otherwise this will result in incorrect code if someone attempts to perform a function call which does clobber these. FPSCR and VSCR are fine to ignore for now since LLVM doesn't model the former and treats the latter as volatile (it's not tracked across instructions, only within a single LLVM pseudo-instruction).

This matches the behavior of fcsr and vxsat on RISC-V. We documented those as managed by preserve_flags in case LLVM does gain support for modeling them in the future so that we can then emit correct clobbers depending on what the asm author intended.

This should only be a documentation change, nothing needs to be done in the code.

• spe_acc, spefscr: These are available exclusively on the SPE target (the e500, not cell). I am not sure how these are actually used. I think they can be added later if needed.

• mma[0-7]: These are new "registers" available on Power10, they are 512b registers which overlay 4x vsx registers. They could be added if needed, however their usage is very specialized.

• ap, mq: I don't think these registers exist on any usable power target supported by gcc/llvm

Even if we don't expose these directly as clobbers, we still need to ensure that clobber_abi properly marks them as clobbered if the default function call ABI treats these as volatile.

I've updated the reference patch require preserving all status and sticky bits of the *scr registers, mq, and acc. Likewise, ap appears to be a pseudo-register for the Argument Register. It's usage isn't described in any ABI's I can find.